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Abstract 


This document defines an extension to the Presence Information Data 


Format Location Object 


(PIDF-LO) 


(RFC 4119) for the expression of 


location information that is defined relative to a reference point. 
The reference point may be expressed as a geodetic or civic location, 


and the relative offset may be one of several shapes. 


An alternative 


binary representation is described. 


Optionally, 
can be included, 


system to the reference/offset coordinate system, 


a reference to a secondary document 
along with the relationship of the map coordinate 


(such as a map image) 


to allow display of 


the map with the reference point and the relative offset. 
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Ls 


Introduction 


This document describes a format for the expression of relative 
location information. 


A relative location is formed of a reference location plus a relative 
offset from that reference location. The reference location can be 
represented in either civic or geodetic form. The reference location 
can also have dynamic components such as velocity. The relative 
offset is specified in meters using a Cartesian coordinate system. 


In addition to the relative location, an optional URI can be provided 
to a document that contains a map, floor plan, or other spatially 
oriented information. Applications could use this information to 
display the relative location. Additional fields allow the map to be 
oriented and scaled correctly. 


Two formats are included: an XML form that is intended for use in 
PIDF-LO [RFC4119] and a TLV format for use in other protocols such as 
those that already convey binary representation of location 
information defined in [RFC4776]. 


Conventions Used in This Document 


The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [RFC2119]. 


Overview 


This document describes an extension to PIDF-LO [RFC4119] as updated 
by [RFC5139] and [RFC5491], to allow the expression of a location as 
an offset relative to a reference. 


Reference 
Location 
o 
N 
\ Offset 
N 
EL 
x 
Relative 
Location 


This extension allows the creator of a location object to include two 
location values plus an offset. The two location values, named 
"baseline" and "reference", combine to form the origin of the offset. 
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The final, relative location is described relative to this reference 
point. 


—-""w__ 
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The baseline location is included outside of the <relative-location> 
element. The baseline location is visible to a client that does not 
understand relative location (i.e., it ignores the 
<relative-location> element). 


A client that does understand relative location will interpret the 
location within the relative element as a refinement of the baseline 
location. This document defines both a reference location, which 
serves as a refinement of the baseline location and the starting 
point, and an offset, which describes the location of the Target 
based on this starting point. 


Creators of location objects with relative location thus have a 
choice of how much information to put into the baseline location and 
how much to put into the reference location. For example, the 
baseline location value could be precise enough to specify a building 
that contains the relative location, and the reference location could 
specify a point within the building from which the offset is 
measured. 


Location objects SHOULD NOT have all location information in the 
baseline location. Doing this would cause clients that do not 
understand relative location to incorrectly interpret the baseline 
location (i.e., the reference point) as the actual, precise location 
of the client. The baseline location is intended to carry a location 
that encompasses both the reference location and the relative 
location (i.e., the reference location plus offset). 


It is possible to provide a valid relative location with no 

information in the baseline. However, this provides recipients who 
do not understand relative location with no information. A baseline 
location SHOULD include sufficient information to encompass both the 
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reference and relative locations while providing a baseline that is 
as accurate as possible. 


Both the baseline and the reference location are defined as either a 
geodetic location [OGC.GeoShape] or a civic address [RFC4776]. If 
the baseline location was expressed as a geodetic location, the 
reference MUST be geodetic. If the baseline location was expressed 
as a civic address, the reference MUST be civic. 


Baseline and reference locations MAY also include dynamic location 
information [RFC5962]. 


The relative location Can be expressed using a point (2- or 
3-dimensional) or a shape that includes uncertainty: circle, sphere, 
ellipse, ellipsoid, polygon, prism, or arc-band. Descriptions of 
these shapes can be found in [RFC5491]. 


Optionally, a reference to a 'map' document can be provided. The 
reference is a URI [RFC3986]. The document could be an image or 
dataset that represents a map, floor plan, or other form. The type 
of document the URI points to is described as a MIME media type 
[RFC2046]. Metadata in the relative location can include the 
location of the reference point in the map as well as an orientation 
(angle from North) and scale to align the document Coordinate 
Reference System (CRS) with the World Geodetic System 1984 (WGS84) 
[WGS84] CRS. The document is assumed to be usable by the application 
receiving the PIDF with the relative location to locate the reference 
point in the map. This document does not describe any mechanisms for 
displaying or manipulating the document other than providing the 
reference location, orientation, and scale. 


As an example, consider a relative location expressed as a point, 
relative to a civic location: 


<presence xmlns="urn:ietf:params:xml:ns:pidf" 
xmlns:dm-"urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:gp-"urn:ietf:params:xml:ns:pidf:geopriv10" 
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" 
xmlns:rel="urn:ietf:params:xml:ns:pidf:geoprivl0:relative" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
entity="pres:relative@example.com"> 

<dm:device id="relativel"> 
<gp:geopriv> 
<gp:location-info> 
<ca:civicAddress xml:lang="en-AU"> 

<ca:country>AU</ca:country> 
<ca:A1>NSW</ca:A1> 
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<ca:A3>Wollongong</ca:A3> 
<ca:A4>North Wollongong</ca:A4> 
<ca:RD>Flinders</ca:RD> 
<ca:STS>Street</ca:STS> 
<ca:HNO>123</ca:HNO> 
</ca:civicAddress> 
<rel:relative-location> 
<rel:reference> 
<ca:civicAddress xml:lang="en-AU"> 
<ca:LMK>Front Door</ca:LMK> 
</ca:civicAddress> 
</rel:reference> 
<rel:offset> 
«gml:Point xmlns:gml-"http://www.opengis.net/gml" 
srsName-"urn:ietf:params:geopriv:relative:2d"» 
<gml:pos>100 50</gml:pos> 
</gml:Point> 
</rel:offset> 
</rel:relative-location> 
</gp:location-info> 
<gp:usage-rules/> 
<gp :method>GPS</gp :method> 
<rel :map> 
<rel:url type="image/png"> 
http://example.com/location/map.png 
</rel:url> 
<rel:offset>20. 120.«/rel:offset» 
<rel:orientation>29.</rel:orientation> 
<rel:scale>20. -20.</rel:scale> 
</rel:map> 
</gp:geopriv> 
<dm: deviceID>mac:1234567890ab</dm: deviceID> 
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> 
</dm:device> 
</presence> 


4. Relative Location 


Relative location is a shape (e.g., point, circle, ellipse). The 
shape is defined with a CRS that has a datum defined as the reference 
(which appears as a civic address or geodetic location in the tuple) 
and the shape coordinates as meter offsets North/East of the datum 
measured in meters (with an optional Z offset relative to datum 
altitude). An optional angle allows the reference CRS be to rotated 
with respect to North. 
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4.1. Relative Coordinate System 


The relative coordinate reference system uses a coordinate system 
with two or three axes. 


The baseline and reference locations are used to define a relative 
datum. The reference location defines the origin of the coordinate 
system. The centroid of the reference location is used when the 
reference location contains any uncertainty. 


The axes in this coordinate system are originally oriented based on 
the directions of East, North, and Up from the reference location: 
the first (x) axis increases to the East, the second (y) axis points 
North, and the optional third (z) axis points Up. All axes of the 
coordinate system use meters as a basic unit. 


Any coordinates in the relative shapes use the described Cartesian 
coordinate system. In the XML form, this uses a URN of 
"urn:ietf:params:geopriv:relative:2d" for two-dimensional shapes and 
"urn:ietf:params:geopriv:relative:3d" for three-dimensional shapes. 
The binary form uses different shape type identifiers for 2D and 3D 
shapes. 


Dynamic location information [RFC5962] in the baseline or reference 
location alters the relative coordinate system. The resulting 
Cartesian coordinate system axes are rotated so that the y axis is 
oriented along the direction described by the «orientation» element. 
The coordinate system also moves as described by the «speed» and 
«heading» elements. 


The single timestamp included in the tuple (or equivalent) element 
applies to all location elements, including all three components of a 
relative location: baseline, reference, and relative. This is 
particularly important when there are dynamic components to these 
items. A location generator is responsible for ensuring the 
consistency of these fields. 


4.2. Placement of XML Elements 


The baseline of the reference location is represented as 
<location-info> like a normal PIDF-LO. Relative location adds a new 
«relative-location» element to «location-info». Within 
«relative-location», «reference» and «offset» elements are described. 
Within «offset» are the shape elements described below. This 
document extends PIDF-LO as described in [RFC6848]. 
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4.3. Binary Format 


This document describes a way to encode the relative location in a 


binary TLV form for use in other protocols that use TLVs to represent 
location. 


A type-length-value encoding is used. 


4------ 4------ 4------ 4------ 4------ 4------ 4------ * 
| Type |Length| value 
4------ 4------ 4------ 4------ 4------ 4------ 4------ * 
| T | N Value 
4------ 4------ 4------ 4------ 4------ 4------ 4------ * 


Figure 1: TLV Tuple Format 


The Type field (T) is an 8-bit unsigned integer. The type codes used 
are registered in an IANA-managed "Relative Location Parameters" 
registry defined by this document and restricted to not include the 
values defined by the "Civic Address Types (CAtypes)" registry. This 
restriction permits a location reference and offset to be coded 
within the same object without type collisions. 


The Length field (N) is defined as an 8-bit unsigned integer. This 
field can encode values from 0 to 255. The length field describes 
the number of bytes in the Value. Length does not count the bytes 
used for the Type or Length. 


The Value field is defined separately for each type. 


Each element of the relative location has a unique TLV assignment. A 
relative location encoded in TLV form includes both baseline and 
reference location TLVs and relative location TLVs. The reference 
TLVs are followed by the relative offset and optional map TLVs 
described in this document. 


4.4. Distances and Angles 
All distance measures used in shapes are expressed in meters. 
All orientation angles used in shapes are expressed in degrees. 
Orientation angles are measured from WGS84 Northing to Easting with 
zero at Northing. Orientation angles in the relative coordinate 


system start from the second coordinate axis (y or Northing) and 
increase toward the first axis (x or Easting). 


Thomson, et al. Standards Track [Page 9] 


RFC 7035 Relative Location October 2013 


4.5. Value Encoding 


The binary form uses single-precision floating-point values 
[IEEE.754] to represent coordinates, distance, and angle measures. 
Single-precision values are 32-bit values with a sign bit, 8 exponent 
bits, and 23 fractional bits. This uses the interchange format 
defined in [IEEE.754] and Section 3.6 of [RFC1014], that is: sign, 
biased exponent and significand, with the most significant bit first. 


Binary-encoded coordinate values are considered to be a single value 
without uncertainty. When encoding a value that cannot be exactly 
represented, the best approximation MUST be selected according to 
[Clinger1990]. 


4.6. Relative Location Restrictions 


More than one relative shape MUST NOT be included in either a PIDF-LO 
or TLV encoding of location for a given reference point. 


Any error in the reference point transfers to the location described 
by the relative location. Any errors arising from an implementation 
not supporting or understanding elements of the reference point 
directly increases the error (or uncertainty) in the resulting 
location. 


4.7. Baseline TLVs 


Baseline locations are described using the formats defined in 
[RFC4776] or [RFC6225]. 


4.8. Reference TLVs 


When a reference is encoded in binary form, the baseline and 
reference locations are combined in a reference TLV. This TLV is 
identified with the code 111 and contains civic address TLVs (if the 
baseline was a civic) or geo TLVs (if the baseline was a geo). 


4+------ 4+------ 4+------ Ho - 4------ 4------ + 
111 | Length | Reference TLVs | 
4+------ 4+------ 4R------ 4R------ 4R------ 4R------ * 


Figure 2: Reference TLV 
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4.9. Shapes 


Shape data is used to represent regions of uncertainty for the 
reference and relative locations. Shape data in the reference 
location uses a WGS84 [WGS84] CRS. Shape data in the relative 
location uses a relative CRS. 


The XML form for shapes uses Geography Markup Language (GML) 
[OGC.GML-3.1.1], consistent with the rules in [RFC5491]. Reference 
locations use the CRS URNs specified in [RFC5491]; relative locations 
use either a 2D CRS ("urn:ietf:params:geopriv:relative:2d") or a 3D 
("urn:ietf:params:geopriv:relative:3d"), depending on the shape type. 


The binary form of each shape uses a different shape type for 2D and 
3D shapes. 


Nine shape type codes are defined. 
4.9.1. Point 


A point "shape" describes a single point with unknown uncertainty. 
It consists of a single set of coordinates. 


In a two-dimensional CRS, the coordinate includes two values; in a 
three-dimensional CRS, the coordinate includes three values. 


4.9.1.1. XML Encoding 
A point is represented in GML using the following template: 
«gml:Point xmlns:gml-"http://www.opengis.net/gml" 
srsName-"$CRS-URN$S"» 
«gml:pos»$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> 
</gml:Point> 
Figure 3: GML Point Template 
Where "SCRS-URNS" is replaced by a 
"urn:ietf:params:geopriv:relative:2d" or 


"urn:ietf:params:geopriv:relative:3d" and "$Coordinate-3$" is omitted 
if the CRS is two-dimensional. 
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4.9.1.2. TLV Encoding 


The point shape is introduced by a TLV of 113 for a 2D point and 114 
for a 3D point. 


+------ +------ + 

| 113/4|Length| 

+------ +------ +------ +------ + 
| Coordinate-1 | 
+------ +------ +------ +------ + 
| Coordinate-2 | 
+------ +------ +------ +------ + 
| (3D-only) Coordinate-3 | 
4£------ 4£------ 4------ 4£------ + 


Figure 4: Point Encoding 
4.9.2. Circle or Sphere Shape 


A circle or sphere describes a single point with a single uncertainty 
value in meters. 


In a two-dimensional CRS, the coordinate includes two values, and the 


resulting shape forms a circle. Ina three-dimensional CRS, the 
coordinate includes three values, and the resulting shape forms a 
sphere. 


4.9.2.1. XML Encoding 


A circle is represented in and converted from GML using the following 
template: 


<gs:Circle xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName-"urn:ietf:params:geopriv:relative:2d"» 
«gml:pos»$Coordinate-1 $Coordinate-2$«/gml:pos» 
<gs:radius uom-"urn:ogc:def:uom:EPSG::9001"» 
SRadius$ 
</gs:radius> 
</gs:Circle> 


Figure 5: GML Circle Template 
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A sphere is represented in and converted from GML using the following 
template: 


«gs:Sphere xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName-"urn:ietf:params:geopriv:relative:3d"» 

«gml:pos»$Coordinate-1 $Coordinate-2$ $Coordinate-3$</gml:pos> 
<gs:radius uom-"urn:ogc:def:uom:EPSG::9001"» 
SRadius$ 
</gs:radius> 
</gs: Sphere> 


Figure 6: GML Sphere Template 
4.9.2.2. TLV Encoding 


A circular shape is introduced by a type code of 115. A spherical 
shape is introduced by a type code of 116. 


4£------ 4£------ + 

| 115/6|Length| 

4£------ 4£------ 4£------ 4£------ + 
| Coordinate-1 | 
4£------ 4£------ 4£------ 4£------ + 
| Coordinate-2 | 
4£------ 4£------ 4£------ 4£------ + 
| (3D-only) Coordinate-3 | 
4£------ 4£------ 4£------ 4£------ + 
| Radius | 
4£------ 4£------ 4£------ 4£------ + 


Figure 7: Circle or Sphere Encoding 
4.9.3. Ellipse or Ellipsoid Shape 


An ellipse or ellipsoid describes a point with an elliptical or 
ellipsoidal uncertainty region. 


In a two-dimensional CRS, the coordinate includes two values plus a 
semi-major axis, a semi-minor axis, a semi-major axis orientation 
(clockwise from North). In a three-dimensional CRS, the coordinate 
includes three values, and in addition to the two-dimensional values, 
an altitude uncertainty (semi-vertical) is added. 
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4.9.3.1. XML Encoding 


An ellipse is represented in and converted from GML using the 
following template: 


<gs:Ellipse xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName="urn:ietf:params:geopriv:relative:2d"> 
«gml:pos»$Coordinate-1 $Coordinate-2$«/gml:pos» 
<gs:semiMajorAxis uom-"urn:ogc:def:uom:EPSG::9001"» 
$Semi-Major$ 
«/gs:semiMajorAxis» 
<gs: semiMinorAxis uom="urn:ogc:def :uom:EPSG: :9001"> 
$Semi-Minor$ 
«/gs:semiMinorAxis» 
<gs:orientation uom-"urn:ogc:def:uom:EPSG::9102"» 
SOrientation$ 
</gs:orientation> 
</gs:Ellipse> 


Figure 8: GML Ellipse Template 


An ellipsoid is represented in and converted from GML using the 
following template: 


<gs:Ellipsoid xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName-"urn:ietf:params:geopriv:relative:3d"» 
«gml:pos»$Coordinate-1 $Coordinate-2$ $Coordinate-3$«/gml:pos» 
<gs:semiMajorAxis uom-"urn:ogc:def:uom:EPSG::9001"» 
$Semi-Major$ 
«/gs:semiMajorAxis» 
<gs: semiMinorAxis uom="urn:ogc:def :uom:EPSG: :9001"> 
$Semi-Minor$ 
«/gs:semiMinorAxis» 
<gs:verticalAxis uom-"urn:ogc:def:uom:EPSG::9001"» 
$Semi-Vertical$ 
</gs:verticalAxis> 
<gs:orientation uom="urn:ogc:def :uom:EPSG: :9102"> 
$Orientation$ 
</gs:orientation> 
</gs:Ellipsoid> 


Figure 9: GML Ellipsoid Template 
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4.9.3.2. TLV Encoding 


An ellipse is introduced by a type code of 117, and an ellipsoid is 
introduced by a type code of 118. 


4------ 4£------ + 

| 117/8|Length| 

4------ 4£------ 4£------ 4£------ + 

| Coordinate-1 | 

+------ +------ 4------ 4------ + 

| Coordinate-2 | 

+—-—---- +------ +------ +------ + 

| (3D-only) Coordinate-3 | 

+------ +------ +------ +—-—---- +—-—---- +------ +------ +------ + 
| Semi-Major Axis | Semi-Minor Axis 

+—-—---- +—-—---- +—-—---- +—-—---- 4£------ 4------ 4£------ 4£------ + 
| Orientation | (3D) Semi-Vertical Axis | 
4------ 4------ 4d------ 4------ 4------ 4------ 4d------ 4£------ + 


Figure 10: Ellipse or Ellipsoid Encoding 
4.9.4. Polygon or Prism Shape 


A polygon or prism includes a number of points that describe the 
outer boundary of an uncertainty region. A prism also includes an 
altitude for each point and prism height. 


At least 3 points MUST be included in a polygon. In order to 
interoperate with existing systems, an encoding SHOULD include 15 or 
fewer points, unless the recipient is known to support larger 
numbers. 
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4.9.4.1. XML Encoding 


A polygon is represented in and converted from GML using the 
following template: 


<gml:Polygon xmlns:gml="http://www.opengis.net/gml" 
srsName="urn:ietf:params:geopriv:relative:2d"> 
<gml:exterior> 
<gml:LinearRing> 
<gml:posList> 
$Coordinatel-1$ $Coordinatel-2$ 
$Coordinate2-1$ $Coordinate2-2$ 
$Coordinate3-1$ 


$CoordinateN-1$ $CoordinateN-2$ 
$Coordinatel-1$ $Coordinatel-2$ 
«/gml:posList» 
«/gml:LinearRing» 
</gml:exterior> 
</gml:Polygon> 


Figure 11: GML Polygon Template 


Alternatively, a series of <pos> elements Can be used in place of the 
single "posList". Each <pos> element contains two or three 
coordinate values. 


Note that the first point is repeated at the end of the sequence of 
coordinates and no explicit count of the number of points is 
provided. 


A GML polygon that includes altitude cannot be represented perfectly 
in TLV form. When converting to the binary representation, a two- 
dimensional CRS is used, and altitude is removed from each 
coordinate. 
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A prism is represented in and converted from GML using the following 
template: 


<gs:Prism xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName-"urn:ietf:params:geopriv:relative:3d"» 
«gs:base» 
«gml:Polygon» 
<gml:exterior> 
<gml:LinearRing> 

<gml:posList> 
$Coordinatel-1$ $Coordinatel-2$ $Coordinatel-3$ 
$Coordinate2-1$ $Coordinate2-2$ S$Coordinate2-3$ 
$Coordinate2-1$ 


$CoordinateN-1$ $CoordinateN-2$ S$CoordinateN-3$ 
$Coordinatel-1$ $Coordinatel-2$ $Coordinatel-3$ 
«/gml:posList» 
«/gml:LinearRing» 
</gml:exterior> 
</gml:Polygon> 
</gs:base> 
<gs:height uom="urn:ogc:def:uom:EPSG::9001"> 
SHeight$ 
</gs:height> 
</gs:Prism> 


Figure 12: GML Prism Template 
Alternatively, a series of <pos> elements can be used in place of the 


single "posList". Each <pos> element contains three coordinate 
values. 


Thomson, et al. Standards Track [Page 17] 


RFC 7035 Relative Location October 2013 


4.9.4.2. TLV Encoding 


A polygon containing 2D points uses a type code of 119. A polygon 
with 3D points uses a type code of 120. A prism uses a type code of 


121. The number of points can be inferred from the length of the 
TLV. 

+—-—---- +—-—---- + 

|119-21 |Length| 

+—-—---- +------ +------ +------ + 
| (3D-only) Height | 
+------ +------ +------ +------ + 
| Coordinatel-1 | 
4£------ 4£------ 4------ 4£------ + 
| Coordinatel-2 | 
4£------ 4------ 4------ 4£------ + 
| (3D-only) Coordinatel-3 | 
4d------ 4------ 4------ 4------ * 
| Coordinate2-1 | 
4------ 4------ 4------ 4£------ * 
4d------ 4------ 4------ 4------ * 
| CoordinateN-1 | 
+—-—---- +—-—---- +------ 4------ + 
| CoordinateN-2 | 
+—-—---- +------ +------ +------ + 
| (3D-only) CoordinateN-3 | 
+------ +------ +------ +------ + 


Figure 13: Polygon or Prism Encoding 


Note that unlike the polygon representation in GML, the first and 
last points are not the same point in the TLV representation. The 
duplicated point is removed from the binary form. 


4.9.5.  Arc-Band Shape 
An arc-band describes a region constrained by a range of angles and 
distances from a predetermined point. This shape can only be 
provided for a two-dimensional CRS. 
Distance and angular measures are defined in meters and degrees, 


respectively. Both are encoded as single-precision floating-point 
values. 
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4.9.5.1. XML Encoding 


An arc-band is represented in and converted from GML using the 
following template: 


<gs:ArcBand xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
srsName-"urn:ietf:params:geopriv:relative:2d"» 
«gml:pos»$Coordinate-1$ $Coordinate-2$</gml:pos> 
<gs:innerRadius uom-"urn:ogc:def:uom:EPSG::9001"» 
$Inner-Radius$ 
«/gs:innerRadius» 
<gs:outerRadius uom-"urn:ogc:def:uom:EPSG::9001"» 
$Outer-Radius$ 
«/gs:outerRadius» 
<gs:startAngle uom-"urn:ogc:def:uom:EPSG::9102"» 
$Start-Angle$ 
</gs:startAngle> 
<gs:openingAngle uom-"urn:ogc:def:uom:EPSG::9102"» 
$Opening-Angle$ 
</gs:openingAngle> 
</gs:ArcBand> 


Figure 14: GML Arc-Band Template 
4.9.5.2. TLV Encoding 


An arc-band is introduced by a type code of 122. 


4------ 4------ + 

| 122 | Length | 

4------ 4------ 4------ 4------ + 

| Coordinate | 

4------ 4------ 4------ 4------ + 

| Coordinate | 

4------ 4------ 4------ 4------ 4------ 4------ 4------ 4------ + 
| Inner Radius | Outer Radius 

4------ 4------ 4------ 4------ 4------ 4------ 4------ 4------ + 
| Start Angle | Opening Angle 

4------ 4------ 4------ 4------ 4------ 4------ 4------ 4------ + 


Figure 15: Arc-Band Encoding 
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4.10. Dynamic Location TLVs 
Dynamic location elements use the definitions in [RFC5962]. 
4.10.1. Orientation 


The orientation of the Target is described using one or two angles. 
Orientation uses a type code of 123. 


+—-—---- +—-—---- + 

| 123 |Length| 

4£------ 4£------ 4£------ 4£------ + 
| Angle | 
+—-—---- +—-—---- 4£------ 4£------ + 
| (Optional) Angle | 
+—-—---- +------ +------ +------ + 


Figure 16: Dynamic Orientation TLVs 
4.10.2. Speed 


The speed of the Target is a scalar value in meters per second. 
Speed uses a type code of 124. 


+------ +------ + 
| 124 | Length | 
+------ 4+------ 4R------ 4R------ * 
| Speed | 
$ $ === - +--==== 4R------ * 


Figure 17: Dynamic Speed TLVs 
4.10.3. Heading 


The heading, or direction of travel, is described using one or two 


angles. Heading uses a type code of 125. 
+------ +------ + 
| 125 |Length| 
+------ +------ +------ +------ + 
| Angle | 
+------ +------ +------ +------ + 
| (Optional) Angle | 
+------ +------ +------ +------ + 


Figure 18: Dynamic Heading TLVs 
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4.11. Secondary Map Metadata 


The optional "map" URL can be used to provide a user of relative 
location with a visual reference for the location information. This 
document does not describe how the recipient uses the map nor how it 
locates the reference or offset within the map. Maps can be simple 
images, vector files, 2D or 3D geospatial databases, or any other 
form of representation understood by both the sender and recipient. 


4.11.1. Map URL 


In XML, the map is a <map> element defined within <relative-location> 
and contains the URL. The URL is encoded as a UTF-8-encoded string. 
An "http:" [RFC2616] or "https:" [RFC2818] URL MUST be used unless 
the entity creating the PIDF-LO is able to ensure that authorized 
recipients of this data are able to use other URI schemes. A "type" 
attribute MUST be present and specifies the kind of map the URL 
points to. Map types are specified as MIME media types as recorded 
in the IANA Media Types registry, for example, <map type="image/png"> 
https: //www.example.com/floorplans/123South/floor-2</map>. 


In binary, the map type is a separate TLV from the map URL. The 
media type uses a type code of 126; the URL uses a type code of 127. 


4R------ 4R------ 4R------ 4R------ 4R------ 4R------ 4R------ * 
| 126 |Length| Map Media Type ums 
4R------ 4R------ 4R------ 4R------ 4R------ 4R------ 4R------ * 
| 127 |Length| Map Image URL 

4R------ 4R------ 4R------ 4R------ 4R------ 4R------ 4R------ * 


Figure 19: Map URL TLVs 


Note that the binary form restricts data to 255 octets. This 
restriction could be problematic for URLs in particular. 
Applications that use the XML form, but cannot guarantee that a 
binary form won't be used, are encouraged to limit the size of the 
URL to fit within this restriction. 


4.11.2. Map Coordinate Reference System 


The CRS used by the map depends on the type of map. For example, a 
map described by a 3-D geometric model of the building may contain a 


complete CRS description in it. For some kinds of maps, typically 
described as images, the CRS used within the map must define the 
following: 
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o The CRS origin 
o The CRS axes used and their orientation 
o The unit of measure used 


This document provides elements that allow for a mapping between the 
local coordinate reference system used for the relative location and 
the coordinate reference system used for the map where they are not 
the same. 


4.11.2.1. Map Reference Point Offset 


This optional element identifies the coordinates of the reference 
point as it appears in the map. This value is measured in a map- 
type-dependent manner, using the coordinate system of the map. 


For image maps, coordinates start from the upper left corner, and 
coordinates are first counted by column with positive values to the 
right; then, rows are counted with positive values toward the bottom 
of the image. For such an image, the first item is columns, the 
second rows, and any third value applies to any third dimension used 
in the image coordinate space. 


The <offset> element contains 2 (or 3) coordinates similar to a GML 
<pos>. For example: 


«offset» 2670.0 1124.0 1022.0«/offset» 


The map reference point uses a type code of 129. 


4£------ 4£------ + 

| 129 | Length | 

+------ +------ 4£------ +------ + 
| Coordinate-1 | 
+------ +------ +------ +------ + 
| Coordinate-2 | 
+------ +------ +------ +------ + 
| (3D-only) Coordinate-3 | 
+------ +------ +------ +------ + 


Figure 20: Map Reference Point Coordinates TLV 


If omitted, a value containing all zeros is assumed. If the 
coordinates provided contain fewer values than are needed, the first 
value from the set is applied in place of any absent values. Thus, 


if a single value is provided, that value is used for Coordinate-2 
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and Coordinate-3 (if required). If two values are provided and three 
are required, the value of Coordinate-l is used in place of 
Coordinate-3. 


4.11.2.2. Map Orientation 


The map orientation includes the orientation of the map direction in 
relation to the Earth. Map orientation is expressed relative to the 
orientation of the relative coordinate system. This means that map 
orientation with respect to WGS84 North is the sum of the orientation 
field and any orientation included in a dynamic portion of the 
reference location. Both values default to zero if no value is 
specified. 


This type uses a single-precision floating-point value of degrees 
relative to North. 


In XML, the <orientation> element contains a single floating-point 
value, for example, <orientation>67.00</orientation>. In TLV form, 
map orientation uses the code 130: 


4------ 4------ 4------ 4------ 4------ 4------ + 
| 130 | Length | Angle 
4------ 4------ 4------ 4------ 4------ 4------ + 


Figure 21: Map Orientation TLV 
4.11.2.3. Map Scale 


The optional map scale describes the relationship between the units 
of measure used in the map, relative to the meters unit used in the 
relative coordinate system. 


This type uses a sequence of IEEE 754 [IEEE.754] single-precision 
floating-point values to represent scale as a sequence of numeric 
values. The units of these values are dependent on the type of map 
and could, for example, be pixels per meter for an image. 


A scaling factor is provided for each axis in the coordinate system. 
For a two-dimensional coordinate system, two values are included to 
allow for different scaling along the x and y axes independently. 

For a three-dimensional coordinate system, three values are specified 
for the x, y, and z axes.  Decoders can determine the number of 
Scaling factors by examining the length field. 


Alternatively, a single scaling value MAY be used to apply the same 
Scaling factor to all coordinate components. 
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Images that use a rows/columns coordinate system often use a left- 
handed coordinate system. A negative value for the y/rows axis 
scaling value can be used to account for any change in direction 
between the y axis used in the relative coordinate system and the 
rows axis of the image coordinate system. 


In XML, the <scale> element MAY contain a single scale value or MAY 
contain 2 (or 3) values in XML list form. In TLV form, scale uses a 
type code of 131. The length of the TLV determines how many scale 
values are present: 


4------ 4------ 4------ 4------ 4------ 4------ * 
| 131 |Length| Scale(s) 
4------ 4------ 4------ 4------ 4------ 4------ * 


Figure 22: Map Scale TLV 
4.11.3. Map Example 
An example of expressing a map is: 


<rel:map> 
<rel:url type="image/jpeg"> 
http://example.com/map.jpg 
</rel:url> 
<rel:offset>200 210«/rel:offset» 
<rel:orientation>68</rel:orientation> 
<rel:scale>2.90 -2.90</rel:scale> 
</rel:map> 


Figure 23: Map Example 
5. Examples 


The examples in this section combine elements from [RFC3863], 
[RFC4119], [RFC4479], [RFC5139], and [OGC.GeoShape]. 


5.1. Civic PIDF with Polygon Offset 


<presence xmlns-"urn:ietf:params:xml:ns:pidf" 
xmlns:dm-"urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:gp-"urn:ietf:params:xml:ns:pidf:geopriv10" 
xmlns:ca="urn:ietf:params:xml:ns:pidf:geopriv10:civicAddr" 
xmlns:rel="urn:ietf:params:xml:ns:pidf:geoprivl0:relative" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
entity="pres:ness@example.com"> 

<dm: device id="nesspc-1"> 
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<gp:geopriv> 
<gp: location-info> 
<ca:civicAddress xml:lang="en-AU"> 
<ca:country>AU</ca:country> 
<ca:A1>NSW</ca:A1> 
<ca:A3>Wollongong</ca:A3> 
<ca:A4>North Wollongong</ca:A4> 
<ca:RD>Flinders</ca:RD> 
<ca:STS>Street</ca:STS> 
<ca:HNO>123</ca:HNO> 
</ca:civicAddress> 
<rel:relative-location> 
<rel:reference> 
<ca:civicAddress xml:lang="en-AU"> 
<ca:LMK>Front Door</ca:LMK> 
<ca:BLD>A</ca:BLD> 
<ca:FLR>I</ca:FLR> 
<ca:ROOM>113</ca:ROOM> 
</ca:civicAddress> 
</rel:reference> 
<rel:offset> 
<gml:Polygon xmlns:gml="http://www.opengis.net/gml" 
srsName="urn:ietf:params:geopriv:relative:2d"> 
<gml:exterior> 
<gml:LinearRing> 
<gml :pos>433. 
<gml :pos>431. 
<gml :pos>431. 
<gml :pos>433. 


-734.0</gml:pos> «!--A--» 
-733.0</gml:pos> «!--F--» 
-732.0</gml:pos> «!--E--» 
-731.0</gml:pos> «!--D--» 
<gml:pos>434.0 -732.0«/gml:pos» <!--C--> 
<gml:pos>434.0 -733.0«/gml:pos» «!--B--» 
<gml:pos>433.0 -734.0«/gml:pos» <!--A--> 
</gml:LinearRing> 
</gml:exterior> 
</gml:Polygon> 
</rel:offset> 
</rel:relative-location> 
</gp:location-info> 
<gp:usage-rules/> 
<gp :method>GPS</gp :method> 
</gp:geopriv> 
«dm:deviceID»mac:1234567890ab«/dm:deviceID» 
<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> 
</dm:device> 
</presence> 


oo0oooo 
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5.2. Geo PIDF with Circle Offset 


<?xml version="1.0" encoding="UTF-8"?> 
<presence xmlns-"urn:ietf:params:xml:ns:pidf" 
xmlns:dm-"urn:ietf:params:xml:ns:pidf:data-model" 
xmlns:gp-"urn:ietf:params:xml:ns:pidf:geopriv10" 
xmlns:rel="urn:ietf:params:xml:ns:pidf:geoprivl0:relative" 
xmlns:gml="http://www.opengis.net/gml" 
xmlns:gs-"http://www.opengis.net/pidflo/1.0" 
entity="pres:point2d@example.com"> 
<dm:device id="point2d"> 
<gp:geopriv> 
<gp: location-info> 
<gs:Circle srsName-"urn:ogc:def:crs:EPSG::4326"» 
<gml:pos>-34.407 150.883«/gml:pos» 
<gs:radius uom="urn:ogc:def:uom:EPSG::9001"> 
50.0 
</gs:radius> 
</gs:Circle> 
<rel:relative-location> 
<rel:reference> 
<gml:Point srsName="urn:ogc:def:crs:EPSG::4326"> 
<gml :pos>-34.407 150.883«/gml:pos» 
</gml:Point> 
</rel:reference> 
<rel:offset> 
«gs:Circle xmlns:gml-"http://www.opengis.net/gml" 
srsName-"urn:ietf:params:geopriv:relative:2d"» 
<gml:pos>500.0 750.0</gml:pos> 
<gs:radius uom-"urn:ogc:def:uom:EPSG::9001"» 
5.0 
</gs:radius> 
</gs:Circle> 
«/rel:offset» 
<rel:map> 
<rel:url type="image/png"> 
https://www.example.com/flrpln/123South/flr-2 
«/rel:url» 
<rel:offset>2670.0 1124.0 1022.0</rel:offset> 
<rel:orientation>67.00</rel:orientation> 
<rel:scale>10 -10</rel:scale> 
</rel:map> 
</rel:relative-location> 
</gp:location-info> 
<gp:usage-rules/> 
<gp:method>Wiremap</gp:method> 
</gp:geopriv> 
«dm:deviceID»mac:1234567890ab«/dm:deviceID» 
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<dm:timestamp>2007-06-22T20:57:29Z</dm:timestamp> 
«/dm:device» 
«/presence» 


5.3. Civic TLV with Point Offset 


4-------- BZ 555-55 5 55 55-555 5-5-5 -- === + 
| Type | Value | 
4-------- BZ ZII 5-5-5 55-55-55 5-5-5 5-5-5 === === + 
| 0 | en | 
| | | 
K | IL | 
| | 
| 3 | Chicago | 
| | | 
| 34 | Wacker | 
| 18 | Drive | 
| | | 
| 19 | 3400 | 
| | | 
112 | Reference 
25 | Building A | 
| | 
1828 | Floor 6 | 
| | | 
| 26 | Suite 213 | 
| 28 | Reception Area 
| | | 
| 115 | 100 70 | 
| | | 
126 | image/png | 
127 | http://maps.example.com/3400Wacker/A6 
| | | 
| 129 | 0.0 4120.0 | 
| | 
| 130 | 113550 | 
| 131 | 10.6 | 
4-------- BZ 5-5-5 55-5 5-5-5 55-5 5-5-5 === + 
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6. Schema Definition 


Note: The pattern value for "mimeType" has been folded onto 
multiple lines. Whitespace has been added to conform to comply 
with document formatting restrictions. Extra whitespace around 
the line endings MUST be removed before using this schema. 


<?xml version="1.0"?> 

<xs:schema 
xmlns:rel-"urn:ietf:params:xml:ns:pidf:geoprivl0:relative" 
xmlns:xs-"http://www.w3.org/2001/XMLSchema" 
xmlns:gml-"http://www.opengis.net/gml" 
targetNamespace="urn:ietf:params:xml:ns:pidf:geoprivl0:relative" 
elementFormDefault="qualified" 
attributeFormDefault="unqualified"> 


<xs:annotation> 
<xs:appinfo 
source-"urn:ietf:params:xml:schema:pidf:geoprivi0:relative"» 
Relative Location for PIDF-LO 

«/xs:appinfo» 

«xs:documentation source-"http://ietf.org/rfc/rfc7035.txt"» 
This schema defines a location representation that allows for 
the description of locations that are relative to another. 

An optional map reference is also defined. 

«/xs:documentation» 

«/xs:annotation» 


«xs:import namespace-"http://www.opengis.net/gml"/» 
«xs:element name-"relative-location" type-"rel:relativeType"/» 


«xs:complexType name="relativeType"> 
«xs:complexContent» 
«xs:restriction base="xs:anyType"> 
<xs : sequence> 
<xs:element name="reference" type="rel:referenceType"/> 
<xs:element name="offset" type="rel:offsetType"/> 
«xs:any namespace="##any" processContents-"lax" 
minOccurs="0" maxOccurs-"unbounded"/» 
«/xs:sequence» 
«xs:anyAttribute namespace="##other" processContents-"lax"/» 
«/xs:restriction» 
«/xs:complexContent» 
«/xs:complexType» 


«xs:complexType name="referenceType"> 
«xs:complexContent» 
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<xs:restriction base="xs:anyType"> 

<xs : sequence> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs-"unbounded"/» 

</xs:sequence> 

</xs:restriction> 

</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="offsetType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element ref="gml:_Geometry"/> 
<xs:any namespace="##other" processContents="lax" 
minOccurs="0" maxOccurs="unbounded"/> 
</xs:sequence> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<xs:element name="map" type="rel:mapType"/> 
<xs:complexType name="mapType"> 
<xs:complexContent> 
<xs:restriction base="xs:anyType"> 
<xs:sequence> 
<xs:element name="url" type="rel:mapUrlType"/> 
<xs:element name="offset" type="rel:doubleList" 
minOccurs="0"/> 
<xs:element name="orientation" type="rel:doubleList" 
minOccurs="0"/> 
<xs:element name="scale" type="rel:doubleList" 
minOccurs="0"/> 
</xs:sequence> 
</xs:restriction> 
</xs:complexContent> 
</xs:complexType> 


<xs:complexType name="mapUrlType"> 
<xs:simpleContent> 
<xs:extension base="xs:anyURI"> 
<xs:attribute name="type" type="rel:mimeType" 
default="application/octet-stream"/> 
</xs:extension> 
</xs:simpleContent> 
</xs:complexType> 


<xs:simpleType name="mimeType"> 
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<xs:restriction base="xs:token"> 


«xs:pattern value="[!#$%&amp;’\*\+\-\.\dA-Z*_*a-z\|~]+ 
/[14$%8&amp; " VÆNHN-V.NVdA=Z" "a-zN|"T+(INt 1*; (ENE 1) * [14$%&amp; 
r\*\H\ GAZA Ja-zV |" ]+=([ 148% amp; EA AAN VdA=Z" "a-zV | "1+] 
&quot; (LH-NINI-71| [Me 1* | NINE 1-771) *&quot; ) ) *"/» 


«/xs:restriction» 
</xs:simpleType> 


«xs:simpleType name="doubleList"> 
<xs:list itemType="xs:double"/> 
</xs:simpleType> 


</xs:schema> 
7. Security Considerations 


This document describes a data format. To a large extent, security 
properties of this depend on how this data is used. 


Privacy for location data is typically important. Adding relative 
location may increase the precision of the location but does not 
otherwise alter its privacy considerations, which are discussed in 
[RFC4119]. 


The map URL provided in a relative location could accidentally reveal 
information if a Location Recipient uses the URL to acquire the map. 
The coverage area of a map, or parameters of the URL itself, could 
provide information about the location of a Target. In combination 
with other information that could reveal the set of potential Targets 
that the Location Recipient has location information for, acquiring a 
map could leak significant information. In particular, it is 
important to note that the Target and Location Recipient are often 
the same entity. 


Access to map URLs MUST be secured with TLS [RFC5246] (that is, 
restricting the map URL to be an https URI), unless the map URL 
cannot leak information about the Target’s location. This restricts 
information about the map URL to the entity serving the map request. 
If the map URL conveys more information about a Target than a map 
server is authorized to receive, that URL MUST NOT be included in the 
PIDF-LO. 
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8. IANA Considerations 
8.1. Relative Location Registry 


This document creates a new registry called "Relative Location 
Parameters". This shares a page, titled "Civic Address Types 
Registry" with the existing "Civic Address Types (CAtypes)" registry. 
As defined in [RFC5226], this new registry operates under "IETF 
Review" rules. 


The content of this registry includes: 


Relative Location Code (RLtype): Numeric identifier, assigned by 
IANA. 

Brief description: Short description identifying the meaning of the 
element. 


Reference to published specification: A stable reference to an RFC 
that describes the value in sufficient detail so that 
interoperability between independent implementations is possible. 


Values requested to be assigned into this registry MUST NOT conflict 
with values assigned in the "Civic Address Types (CAtypes)" registry 
or vice versa, unless the IANA Considerations section for the new 
value explicitly overrides this prohibition and the document defining 
the value describes how conflicting TLV codes will be interpreted by 
implementations. To ensure this, the CAtypes entries are explicitly 
reserved in the initial values table below. Those reserved entries 
can be changed, but only with caution, as explained here. 


To make this clear for future users of the registry, the following 
note is added to the "Civic Address Types (CAtypes)" registry: 


The registration of new values should be accompanied by a 
corresponding reservation in the Relative Location Parameters 
registry. 


Similarly, the "Relative Location Parameters" registry bears the 
note: 


The registration of new values should be accompanied by a 


corresponding reservation in the Civic Address Types (CAtypes) 
registry. 
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The values defined are: 
4-------- 4---------------------------------------- 
| RLtype | description 
4-------- ENE SEE EE E O mm Se esses 
| 0-40 | RESERVED by CAtypes registry 
| 128 | 
4-------- 4---------------------------------------- 
111 relative location reference 
113 relative location shape 2D point 
| 114 | relative location shape 3D point 
| 115 | relative location shape circular 
| 116 | relative location shape spherical 
| 117 | relative location shape elliptical 
| 118 | relative location shape ellipsoid 
119 relative location shape 2D polygon 
| 120 | relative location shape 3D polygon 
| 121 | relative location shape prism 
| 122 | relative location shape arc-band 
| 123 | relative location dynamic orientation 
| 124 | relative location dynamic speed 
125 | relative location dynamic heading 
| 126 relative location map type 
| 352 | relative location map URI 
| 129 | relative location map coordinates 
| 130 | relative location map angle 
| 131 | relative location map scale 
4-------- += === +++ 
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8.2. URN Sub-Namespace Registration 


This document registers a new XML namespace, as per the guidelines in 
[RFC3688]. 


URI: urn:ietf:params:xml:ns:pidf:geoprivl0:relative 


Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 
Martin Thomson (martin.thomson@skype.net). 


XML: 


BEGIN 
<?xml version="1.0"?> 
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" 
"http://www.w3.org/IR/xhtmll/DTD/xhtmll-strict.dtd"» 
«html xmlns-"http://www.w3.org/1999/xhtml" xml:lang="en"> 
«head» 
<title>GEOPRIV Relative Location</title> 
</head> 
<body> 
<hl>Format for representing relative location</h1> 
«h2»urn:ietf:params:xml:ns:pidf:geoprivl0:relative«c/h2» 
<p>See «a href-"http://www.rfc-editor.org/rfc/rfc7035.txt"» 
RFC 7035</a>.</p> 
</body> 
</html> 


END 
8.3. XML Schema Registration 


This section registers an XML schema as per the procedures in 
[RFC3688]. 


URI: urn:ietf:params:xml:schema:pidf:geoprivl0:relative 


Registrant Contact: IETF, GEOPRIV working group (geopriv@ietf.org), 
Martin Thomson (martin.thomson@skype.net) 


Schema: The XML for this schema is found in Section 6 of this 
document. 
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8. 


4. 


Geopriv Identifiers Registry 


This section registers two URNs for use in identifying relative 


coordinate reference systems. These are added to a new "Geopriv 
Identifiers" registry according to the procedures in Section 4 of 
[RFC3553]. The "Geopriv Identifiers" registry is entered under the 


"Uniform Resource Name (URN) Namespace for IETF Use" category. 


Registrations in this registry follow the "IETF Review" [RFC5226] 
policy. 


Registry name:  Geopriv Identifiers 

URN Prefix:  urn:ietf:params:geopriv: 

Specification: RFC 7035 (this document) 

Repository:  http://www.iana.org/assignments/geopriv-identifiers 

Index value: Values in this registry are URNs or URN prefixes that 
start with the prefix "urn:ietf:params:geopriv:". Each is 


registered independently. 


Each registration in the "Geopriv Identifiers" registry requires the 
following information: 


URN: The complete URN that is used or the prefix for that URN. 
Description: A summary description for the URN or URN prefix. 


Specification: A reference to a specification describing the URN or 
URN prefix. 


Contact: Email for the person or groups making the registration. 
Index value: As described in [RFC3553], URN prefixes that are 
registered include a description of how the URN is constructed. 


This is not applicable for specific URNs. 


The "Geopriv Identifiers" registry has two initial registrations, 
included in the following sections. 
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8.4.1. Registration of Two-Dimensional Relative Coordinate Reference 
System URN 


This section registers the "urn:ietf:params:geopriv:relative:2d" URN 
in the "Geopriv Identifiers" registry. 


URN: urn:ietf:params:geopriv:relative:2d 
Description: A two-dimensional relative coordinate reference system 
Specification:  RFC 7035 (this document) 


Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin 
Thomson (martin.thomson@skype.net) 


Index value: N/A 


8.4.2. Registration of Three-Dimensional Relative Coordinate Reference 
System URN 


This section registers the "urn:ietf:params:geopriv:relative:3d" URN 
in the "Geopriv Identifiers" registry. 


URN: urn:ietf:params:geopriv:relative:3d 


Description: A three-dimensional relative coordinate reference 
system 


Specification: RFC 7035 (this document) 


Contact: IETF, GEOPRIV working group (geopriv@ietf.org), Martin 
Thomson (martin.thomson@skype.net) 


Index value: N/A 
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